PSUDP: A Passive Approach to Network-Wide Covert Communication

This paper explores taking a passive approach to covert communication over DNS. By exploiting the slack space that can be created in DNS packets, data may be inserted into packets without affecting the operation of DNS resolvers and security tools. Several locations in the packet exist that allow additional data to be inserted into the network traffic without being noticed by applications before or at the destination host. Unlike many of the low-bandwidth covert channels such as port numbers and identification fields, this method is an enabler for high-bandwidth communication between multiple systems. This method is introduced through PSUDP, a tool that creates a network-wide messaging system by piggy-backing on legitimate network DNS traffic. By creating a broker system on the DNS server, clients can communicate by injecting messages and desired recipients into DNS requests destined for the broker. These messages are then held at the broker until they may be passively delivered to the appropriate client in a legitimate DNS response. By relying on traffic that is already traveling through the network, no additional packets must be created for this messaging system. The programs discussed in this paper are proof of concept implementations that are harmless “as is”. The techniques are demonstrated in non-malicious tools so the security community can learn from them and be able to identify this method of communication. For this reason, advanced data hiding techniques and protocol features such as reliability and sequencing were left out of the tools. Introduction While a large number of application layer protocols exist, they are all built from a small number of transport and network layer protocols. Currently, it is uncommon for network devices to perform deep packet inspection (DPI), analyzing the actual application layer content of the data carried by the transport layers. Instead, most devices simply use the length field specified by the lower layer protocols to forward the appropriate number of bytes to the destination host. Passive manipulation of network traffic implies that no additional network packets are created. Instead, existing network traffic is manipulated to carry additional information (often covert) between the two systems. Because DNS is used by nearly all hosts in a network, it is ideal for demonstrating the possibilities of covert communication over protocol slack space. The domain name system (DNS) is a hierarchical network of systems responsible for resolving domain names to IP addresses. A fully qualified domain name (FQDN) is formed through a series of labels that separate it into subdomains, each one controlled by the subdomain to its right. RFC 1035 specifies the allowable characters as a-Z, 0-9, and dashes (Mockapetris 1987). Additionally, the RFC limits the labels to 63 octets or less, with the full domain being 255 octets or less. DNS tunnels have gained significant popularity as a mechanism for bypassing network policies and infiltrating/exfiltrating data. Similarly, they have proven ideal for establishing communication links for botnets or other malicious software. Since DNS is required on all networks requiring internet access, it can easily be used to provide storage or timing channels for restricted protocols that would not have access out of the network, otherwise. Additionally, DNS traffic is typically less monitored than protocols such as HTTP or SMTP, often only being closely examined when issues occur. Related Work Several DNS tunnel implementations exist that allow policy-restricted application layer protocols (ALP) to be transported inside DNS traffic. Ozyman, TCP-over-DNS, Iodine, Dns2tcp, DNScat, and DeNiSe are all examples of popular DNS tunnels that allow users to bypass firewall restrictions. While they all use similar tactics for storing data in queries (encoding data in the subdomain), many of them use slightly different strategies for responses. Some tunnels, such as TCP-over-DNS (TCP-Over-DNS 2008) and Dns2tcp (Dembour 2008), use TXT records to exfiltrate data in responses. TXT records are convenient because they allow free form text to be included in the response. Other tunnels like Iodine (Iodine 2009) use NULL record types to store data. Neither method is particularly covert since heavy amounts of TXT or NULL record types coming from standard desktop systems should throw red flags in most networks. DNScat (Pietraszek 2004) uses yet another method of tunneling data in responses by creating custom CNAME records. While this method is slightly more complex, it offers greater covertness since CNAME records are a more common resource record type than TXT or NULL records. Reverse DNS tunneling shellcode was explored by Ty Miller (Miller 2008). In his work, DNS tunnels were used because of their ability to escape internal networks easier than HTTP, which often requires authentication. Miller forced exploited clients to probe the attacker‟s domain, allowing commands to be tunneled back to the internal system. Many interesting strategies were introduced with the release of Heyuka (Revelli 2009). Revelli and Leidecker showed that many DNS servers would accept binary data in domain name labels, increasing their bandwidth from 5 bits per character to 8 bits per character. Additionally, they took advantage of EDNS0 to increase the bandwidth ceiling from 512 bytes per packet to 1024 bytes per packet. Covertness was added by spoofing packets across a range of IP addresses instead of from a single system. Recently, I showed how data could be exfiltrated over DNS without additional software or privileges by executing a local JavaScript file in a browser. In this work, it is demonstrated how DNS queries may be separated from their respective HTTP requests, creating a covert DNS storage channel. Additionally, it was shown how low-bandwidth bidirectional tunnels could be created through both storage and timing channels (Born 2010). The tools demonstrated in this work differ from all past work in that it uses a new, higher-bandwidth method of creating storage channels. Additionally the method proposed may be used passively by piggy-backing on legitimate traffic instead of actively generating new packets. DNS Packet Length When network devices receive a packet, they are able to use the length field specified at the IP layer to determine the size of the transport layer data. While not present in TCP, the UDP protocol additionally has its own length field that allows programs to calculate the size of the application layer data. According to RFC 1035 (Mockapetris 1987), DNS packets are restricted to a UDP length of 512 bytes. However, this can be extended to 1024 bytes by using the EDNS0 extension (Pixie 1999). Every DNS query and response has two parts: the header section and the resource record sections. While the resource record sections are variable in length, the header is always contained in the initial 12 bytes. The header first contains an identification field followed by various parameters and flags describing the packet. Lastly, several fields describe how many of each of the four resource record types will be found in the resource record sections. This count information is used by the DNS parser to determine when the end of a section type is reached. Each label in a stored domain name is preceded by an eight bit field specifying the length of the label. A parser knows it has reached the end of a domain when it reads a 0 from the length field. When a domain or a list of labels has been declared by a previous resource record, a pointer to that location may be used instead to reduce the size of messages. Figure 1: Label Format Use of the compressed DNS form is optional for servers, making the packet length of domain names variable. For this reason, the parser has no way of easily calculating how much storage space is actually required for a set of domains. Similarly, many resource record types have a variable RDATA length (retrieved from the RDLENGTH field). Both the domain length and the RDLENGTH are required before knowing the total resource record size. Unlike the IP and UDP headers, The DNS header does not store the total length of the packet. This information must be derived through the UDP and IP headers which store the total length of both their headers and data, respectively. Defeating the Parser Because DNS headers do not contain information about the length of the resource records or total packet, parsers rely on the number of resource records specified in the DNS header to determine when to stop parsing the data. When the last resource record specified in the header has been parsed, it is assumed that the end of the data has been reached. However, by manipulating the IP and UDP headers to account for additional length, it is possible to append any amount of binary data to the end of the DNS packet without adversely affecting how DNS servers and resolvers react to manipulated DNS queries and responses. Since the storage channel is not restricted to label-based characters or special formatting like many channels used in DNS tunnels, a significantly higher ceiling of data storage may be reached. Additionally, the use of non-ASCII characters is much less identifiable when the raw packets are examined. By modifying the IP and UDP length headers, the additional data will not be dropped as the packet is passed through the network. Figure 2: Injected Packet The storage channel capacity of each packet may be calculated by looking at the UDP header‟s length field. For example, if the UDP packet length is 200 bytes, the storage channel capacity can be calculated as 512200 = 312 bytes. The ceiling for DNS packet length may be extended to 1024 bytes by combining this strategy with the EDNS0 extension. One problem with this strategy is that the covert channel is always located at the end of the data, simplifying detection. An ideal channel would allow the data to be more covertly hidden in the middle of the packet, making it more difficult to identify when looking at the packets through analysis tools such as Wireshark.